“Refactoring” Refactoring

Code refactoring’s primary impetus is to control technical debt, a metaphor for the cost in software development due to the extraneous human effort needed to resolve confusing, obfuscatory, or hastily-crafted program code. While these issues are often described as causing “bad smells,” not all bad smells emanate from the code itself. Some (often the most pungent and costly) originate in the formation, or expressions, of the antecedent intensions the software proposes to satisfy. Paying down such technical debt requires more than grammatical manipulations of the code. Rather, refactoring in this case must attend to a more inclusive perspective; particularly how stakeholders perceive the artifact; and their conception of quality – their appreciative system. First, this paper explores refactoring as an evolutionary design activity. Second, we generalize, or “refactor,” the concept of code refactoring, beyond changes to code structure, to improving design quality by incorporating the stakeholders’ experience of the artifact as it relates to their intensions. Third, we integrate this refactored refactoring as the organizing principle of design as a reflective practice. The objective is to improve the clarity, understandability, maintainability, and extensibility manifest in the stakeholder intensions, in the artifact, and in their interrelationship

The Empire Strikes Back: The end of Agile as we know it?

Agile methods have co-evolved with the onset of rapid change in software and systems development and the methodologies and process models designed to guide them. Conceived from the lessons of practice, Agile methods brought a balanced perspective between the intentions of the stakeholder, the management function, and developers. As an evolutionary progression, trends towards rapid continuous delivery have witnessed the advent of DevOps where advances in tooling, technologies, and the environment of both development and consumption exert a new dynamic into the Agile oeuvre. We investigate the progression from Agile to DevOps from a Critical Social Theoretic perspective to examine a paradox in agility – does an always-on conceptualization of production forestall and impinge upon the processes of reflection and renewal that are also endemic to Agile methods? This paper is offered as a catalyst for critical examination of and as a call to action to advocate for sustaining and nurturing reflective practice in Agile and post-Agile methods, such as DevOps. Under threat of disenfranchisement and relegation to automation, we question how evolution towards DevOps may alter key elements in the tenets and principles of the Agile methods phenomenon

The end of Agile as we know it?

Agile methods have co-evolved with the onset of rapid change and turbidity in software and systems development and the methodologies and process models designed to guide them. Conceived from the lessons of practice, Agile methods brought a balanced perspective between the intensions of the stakeholder, the management function, and developers. As an evolutionary progression, trends towards rapid continuous delivery have witnessed the advent of DevOps where advances in tooling, technologies, and the environment of both development and consumption exert a new dynamic into the Agile oeuvre. We investigate the progression from Agile to DevOps from a Critical Social Theoretic perspective to examine a paradox in agility – what does an always-on conceptualization of production forestall and impinge upon the processes of reflection and renewal that are also endemic to Agile methods? This paper is offered as a catalyst for critical examination and as an overt call to action to engage in emancipatory scholarship in advocacy for the Agile development team. Under threat of disenfranchisement and relegation to automation, we question how a tilt towards DevOps will preserve key elements in the tenets and principles of the Agile methods phenomenon